As an enhancement to the release99/release4 (rel99/rel4) downlink shared channel (DSCH) concept in the third generation partnership project (3GPP) shown in FIG. 1(a) it has been agreed to add a so-called High Speed Downlink Packet Access (HSDPA) concept as a part of the 3GPP rel5 universal terrestrial radio access network (UTRAN) architecture as shown in FIG. 1(b). In FIG. 1(a) the DSCH is transmitted on a downlink Physical Downlink Shared CHannel (PDSCH) 10. In principle, the new HSDPA concept of FIG. 1(b) is an enhancement, because the leading idea in 3GPP has been to make HSDPA as an evolution from the shared channel concept not as a revolution. Therefore the defined solutions should resemble as much as possible the solutions which have already been defined for the shared channels. The basic idea behind the HSDPA is to offer a shared high speed channel with a higher data rate and a quick retransmission mechanism (i.e. with HARQ (=Hybrid Automatic Repeat Request)) from Node B. As can be seen by comparing FIG. 1(b) to FIG. 1(a), the Node B is given more intelligence for the purpose of handling retransmissions and scheduling functions, thus reducing the round trip delay between the mobile device and the RNC formerly handling retransmissions in FIG. 1(a). This makes retransmission combining feasible in the mobile device. In place of the variable spreading factor and fast power control used for the DSCH of FIG. 1(a), the HS-DSCH of FIG. 1(b) uses adaptive modulation and coding (AMC) in addition to the HARQ. A much smaller transmission time interval (TTI) of two milliseconds is also used instead of the 10 or 20 milliseconds of the DSCH. Also, the media access control (MAC) is located in the node B instead of the RNC. The AMC part of HSDPA utilizes adaptation of code rate, the modulation scheme, the number of multi-codes employed, as well as the transmit power per code. Even though many parameters are defined in the Radio Network Subsystem Application Part (RNSAP; see 3GPP TS25.423 v5.0.0) and Node B Application Part (NBAP; see 3GPP TS25.433 v5.0.0) to support HSDPA, the HSDPA discussion is on-going in 3GPP and many useful parameters are being added.
The user equipment is able to send a channel quality indicator (CQI) on the uplink HS-DPCCH (high speed dedicated physical control channel). It indicates the selected transport format resource combination (TFRC) and multi-code number currently supported by the UE.
FIG. 1(c) shows further details of the proposed UTRAN side overall MAC architecture including the new MAC-hs. MAC-hs provides the essential functionalities to support HSDPA. MAC-hs has the scheduling function as well as HARQ.
FIG. 2 shows a radio protocol architecture for HSDPA taken from FIG. 5.1-1 of 3GPP TS 25.308 v5.2.0 (2002-03). According to that specification, the new functionalities of hybrid ARQ and HSDPA scheduling are included in the MAC layer. In the UTRAN these functions are included in a new entity called MAC-hs located as shown in the Node B in FIG. 2. The transport channel that the HSDPA functionality will use is called HS-DSCH (High Speed Downlink Shared Channel) and is controlled by the MAC-hs. The MAC protocol configuration shown is one of two possible configurations on the UTRAN side presented in the aforementioned specification. The illustrated configuration is provided with MAC-c/sh. In this case, the MAC-hs in Node B is located below MAC-c/sh in the RNC. MAC-c/sh provides functions to HSDPA already included for DSCH in the Release '99. The HS-DSCH FP (frame protocol) will handle the data transport from SRNC to CRNC (if the Iur interface is involved) and between CRNC and the Node B. Another configuration without MAC-c/sh is possible. In that case (see FIG. 5.1-2 of the aforementioned specification, the CRNC does not have any user plane function for the HS-DSCH. MAC-d in SRNC is located directly above MAC-hs in Node B, i.e. in the HS-DSCH user plane the SRNC is directly connected to the Node B, thus bypassing the CRNC. Both configurations are transparent to both the UB and Node B. FIG. 2 hereof shows the respective radio interface protocol architecture with termination points. The same architecture supports both FDD and TDD modes of operation, though some details of the associated signalling for HS-DSCH are different.
FIG. 3 (see FIG. 6.2.2-1 of 3GPP TS 25.308 v5.2.0) shows UTRAN side MAC architecture/MAC-c/sh details. The data for the HS-DSCH is subject to flow control between the serving and the drift RNC. A new flow control function is included to support the data transfer between MAC-d and MAC-hs.
FIG. 4 shows UTRAN side MAC architecture/MAC-hs details (see FIG. 6.2.3-1 of 3GPP TS 25.308 v5.2.0). According to section 6.2.3 of the aforementioned specification, the MAC-hs is responsible for handling the data transmitted on the HS-DSCH. Furthermore it is its responsibility to manage the physical resources allocated to HSDPA. MAC-hs receives configuration parameters from the RRC layer via the MAC-Control SAP. There shall be priority handling per MAC-d PDU in the MAC-hs. The MAC-hs is comprised of four different functional entities:
Flow Control:
This is the companion flow control function to the flow control function in the MAC-c/sh in case of Configuration with MAC-c/sh and MAC-d in case of Configuration without MAC-c/sh. Both entities together provide a controlled data flow between the MAC-c/sh and the MAC-hs (Configuration with MAC-c/sh) or the MAC-d and MAC-hs (Configuration without MAC-c/sh) taking the transmission capabilities of the air interface into account in a dynamic manner. This function is intended to limit layer 2 signalling latency and reduce discarded and retransmitted data as a result of HS-DSCH congestion. Flow control is provided independently by priority class for each MAC-d flow.
Scheduling/Priority Handling:
This function manages HS-DSCH resources between HARQ entities and data flows according to their priority class. Based on status reports from associated uplink signalling either new transmission or retransmission is determined. Further it sets the priority class identifier and TSN for each new data block being serviced. To maintain proper transmission priority a new transmission can be initiated on a HARQ process at any time. The TSN is unique to each priority class within a HS-DSCH, and is incremented for each new data block. It is not permitted to schedule new transmissions, including retransmissions originating in the RLC layer, within the same TTI, along with retransmissions originating from the HARQ layer.
HARQ:
One HARQ entity handles the hybrid ARQ functionality for one user. One HARQ entity is capable of supporting multiple instances (I-JARQ process) of stop and wait HARQ protocols. There shall be one HARQ process per TTI.
TFC selection:
Selection of an appropriate transport format and resource combination for the data to be transmitted on HS-DSCH.
Currently in 3GPP, the SRNC is supposed to send the CQI Power Offset, ACK Power Offset and NACK Power Offset to the UE via RRC layer messages. The Power Offsets will be defined as relative to the DPCCH pilot bit. Then the UE will use these Power Offsets as follows:
When an uplink HS-DPCCH is active, the relative power offset HS-DPCCH between the DPCCH and the HS-DPCCH for each HS-DPCCH slot shall be set as follows: For HS-DPCCH slots carrying HARQ Acknowledgement:    ΔHS-DPCCH=ΔACK if the corresponding HARQ Acknowledgement is equal to 1    ΔHS-DPCCH=ΔNACK if the corresponding HARQ Acknowledgement is equal to 0For HS-DPCCH slots carrying CQI:    ΔHS-DPCCH=ΔCQI The values for ΔACK, ΔNACK and ΔCQI are set by higher layers (RRC message). The quantization of the power offset can be found in 3GPP TS 25.213 at Table 1A for instance.